add errorprone's ClassInitializationDeadlock #7021
Conversation
Closes micrometer-metricsgh-6998 Signed-off-by: Emanuel Trandafir <[email protected]>
|
I would vote for suppression unless you fix the issue in the same PR :) |
|
@etrandafir93 good find on the errorprone check I didn't realize was available (probably a sign we have too many errorprone warnings that people tend to ignore them). |
Closes micrometer-metricsgh-6998 Signed-off-by: Emanuel Trandafir <[email protected]>
|
The rule existed on errorprone's catalog, but it was not configured for the micrometer project. I've added it in my first commit to see the build failing, and then suppress the warning for our 3 known issues in the 2nd commit. So yes, if we add this anti-pattern again, the build will fail 👍 |
|
Thanks for the quick updates. |
|
@shakuzen - yes, ready for merge. |
…s#7021) This ensures we do not introduce new cases of this issue by failing the build when they are detected by ErrorProne. It suppresses the warning on the existing cases we are aware of while we separately decide what to do about them. See micrometer-metricsgh-6998 Signed-off-by: Emanuel Trandafir <[email protected]>
3 participants
@shakuzen, @marcingrzejszczak
Turns out there was an errorprone rule already that should guard against the exact issue we found in #6946
https://errorprone.info/bugpattern/ClassInitializationDeadlock
They even suggest some fixes, but all of them seem to introduce breaking changes
This successfully found 3 occurrences of this pattern: see job logs
Should we suppress the 3 errors for now, so that we can merge this? Or are we going to tackle the issue soon?
See gh-6998